Space-Efficient Gradual Typing

Gradual type systems offer a smooth continuum between static and dynamic typing by permitting the free mixture of typed and untyped code. The runtime systems for these languages—and other languages with hybrid type checking—typically enforce function types by dynamically generating function proxies. This approach can result in unbounded growth in the number of proxies, however, which drastically impacts space efficiency and destroys tail recursion. We present an implementation strategy for gradual typing that is based on coercions instead of function proxies, and which combines adjacent coercions to limit their space consumption. We prove bounds on the space consumed by coercions as well as soundness of the type system, demonstrating that programmers can safely mix typing disciplines without incurring unreasonable overheads. Our approach also detects certain errors earlier than prior work. 1 GRADUAL TYPING FOR SOFTWARE EVOLUTION Dynamically typed languages have always excelled at exploratory programming. Languages such as Lisp, Scheme, Smalltalk, and JavaScript support quick early prototyping and incremental development without the overhead of documenting (oftenchanging) structural invariants as types. For large applications, however, static type systems have proven invaluable. They are crucial for understanding and enforcing key program invariants and abstractions, and they catch many errors early in the development process. Given these different strengths, it is not uncommon to encounter the following scenario: a programmer builds a prototype in a dynamically-typed scripting language, perhaps even in parallel to a separate, official software development process with an entire team. The team effort gets mired in process issues and overengineering, and the programmer’s prototype ends up getting used in production. Before long, this hastily conceived prototype grows into a full-fledged production system, but without the structure or guarantees provided by static types. The system becomes unwieldy; QA can’t produce test cases fast enough and bugs start cropping up that no one can track down. Ultimately, the team decides to port the application to a statically typed language, requiring a complete rewrite of the entire system. The cost of cross-language migration is huge and often insupportable. But the scenario above is avoidable. Several languages combine static and dynamic typing, among them Boo [7], Visual Basic.NET [19], Sage [16], and PLT Scheme [24]. This approach of hybrid typing, where types are enforced with a combination of